Configuring .NET Trust Levels
The
.NET Framework technology provides Web developers with a strong set of
features for implementing applications. The functionality includes Web
applications (based on the ASP.NET platform) as well as other managed
code features. It is relatively simple to create .NET applications that
can perform a wide array of operations on a computer. From a security
standpoint, however, it is important to restrict the permissions that
are granted to a .NET application. Malicious or defective code can
cause problems ranging from unauthorized access to data to the
accidental deletion of content.
To
help systems administrators manage permissions on production servers
better, IIS supports Code Access Security (CAS) policy. CAS policies
can be used to determine which operations are available to .NET-based
application code. There are two main types of configuration. The full
trust option provides ASP.NET application code with all permissions on
the computer. For compatibility reasons, this is the default setting
for applications that are based on the .NET Framework 1.0, 1.1, and 2.0.
Understanding Partial Trust Levels
The
other CAS policy option is partial trust, which limits the actions .NET
applications can perform. These options are available to applications
that are built using .NET Framework 1.1 and .NET Framework 2.0. The
goal with partial trust is to enable only the permissions that are
necessary for a specific Web application.
Trust levels can be configured at different levels in the Web server object hierarchy. These levels include:
As
with other security-related settings, trust levels that are defined at
parent levels automatically apply to child objects unless they are
specifically overridden. In general, define .NET Trust Level settings
at the highest relevant setting. For example, if none of the Web
applications in a Web site should have full permissions, you can
configure these settings at the site level. You can then manage
exceptions by assigning the necessary .NET Trust Level settings for
specific Web applications or folders.
Understanding .NET Trust Levels
The
.NET Framework contains many features and operations that potentially
can cause security issues on a Web server. To provide a simpler method
of configuring and applying trust settings, IIS includes five built-in
levels that can be applied to IIS objects. The specific settings for
each level are defined within various .config files.It is also possible to view and modify the settings in these files by using an XML editor or text editor. Table 2 lists the levels and their effects.
Table 2. .NET Trust Levels and Their Descriptions
| .NET Trust Level | .Config File Name | Description | Restricted Actions |
|---|
| Full (internal) | N/A | Provides full permissions to an ASP.NET application | N/A |
| High | Web_hightrust.config | Provides access to most actions on the server and is designed for well-trusted and well-tested Web applications |
|
| | | |
|
| | | | |
| | | |
|
| | | |
|
| Medium | Web_medium trust.config | Provides additional restrictions for Web applications that should not need to access the file system or registry | |
| | | |
|
| | | | |
| Low | Web_lowtrust.config | Further restricts application capabilities | |
| | | |
|
| Minimal | Web_minimal trust.config | Allows only execute permissions and prevents access to other resources on the computer | Performing actions that require permissions greater than Execute |
The
default setting is Full (internal), which provides the best
compatibility but also the greatest security risk. Whenever possible,
lower the .NET Trust Levels to ensure that application code is being
run with minimal permissions. Often, this will involve interactions
with Web developers to determine requirements and perform complete
testing at various security levels.
Configuring .NET Trust Levels
To
configure .NET Trust Levels using IIS Manager, select the object for
which you want to assign the settings, and then double-click .NET Trust
Levels from Features View. (See Figure 25.)
To change the setting, select the appropriate level from the drop-down
list, and click Apply. Once the trust level is set, it will apply to
all ASP.NET applications running at the selected level as well as any
child objects unless the settings are explicitly overridden.
Practice: Securing Web Servers and Web Content
In
these exercises, you will apply the information you learned about ways
to add security to specific Web content. The steps assume that you have
installed the Web Server (IIS) role using the default settings and that
you are familiar with the process of adding role services.
▸ Exercise 1 Manage and Test Authentication Settings
In this exercise, you will configure and verify the effects of various authentication settings.
1. | Log on to Server2 as a user with Administrator permissions.
|
2. | Using Server Manager, add the following role services to the Web Server (IIS) role:
|
3. | When you are finished, close Server Manager.
|
4. | Open
IIS Manager and select Default Web Site in the left pane. Double-click
Authentication in Features View. Note that the default settings specify
that only anonymous authentication is enabled.
|
5. | Click
Default Web Site, and then click Browse *:80 (http) in the Actions
pane. Verify that the default IIS start page is displayed. Keep the Web
browser open but return to IIS Manager.
|
6. | Again, double-click Authentication in Features View. Select Windows Authentication, and then click Enable in the Actions pane.
|
7. | Return to Internet Explorer and refresh the Web page.
Note that you are not prompted to provide authentication information.
This is because anonymous authentication is still enabled for the site.
|
8. | Return to IIS Manager, select anonymous authentication, and then click Disable in the Actions pane.
|
9. | Return
to Internet Explorer and notice that this time you are prompted to
provide logon information to access the site. Enter your username and
password, and then click OK to verify that the site loads. Optionally,
you can provide invalid logon information (such as a user account that
does not exist) to see that you will be unable to access the site. When
you are finished, close Internet Explorer.
|
10. | To
restore the original authentication settings, return to IIS Manager.
Disable Windows Authentication and enable anonymous authentication.
|
11. | When you are finished, close IIS Manager.
|
▸ Exercise 2 Configure Server Certificates
In
this exercise, you will create a self-signed security certificate for
Server2.contoso.com. You will then require SSL to access Default Web
Site and test the settings, using Internet Explorer.
1. | Log on to Server2 as a user with Administrator permissions on the computer.
|
2. | Open IIS Manager and select the server object in the left pane.
|
3. | Double-click Server Certificates in the IIS section of Features View.
Note that, depending on which roles and role services have been
installed on the local server, there might already be some certificates
available on the server.
|
4. | Click Create Self-Signed Certificate in the Actions pane.
|
5. | For the name of the certificate, type Test Local SSL Certificate, and then click OK.
You should now see the new certificate in the Server Certificates view of IIS Manager.
|
6. | To view the properties of the new certificate, right-click it, and select View.
Note details such as the issuer (which is the name of the server) and
the dates for which the certificate is valid. (New certificates expire
in one year.) The Certification Path tab will show only the certificate
itself, signifying that it has not been issued by a trusted Certificate
Authority (CA). For this reason, the certificate is not suited for
access by users on public networks such as the Internet.
|
7. | Click OK when you are finished.
|
8. | In
IIS Manager, right-click the Default Web Site object, and select Edit
Bindings. Select the HTTPS binding type, and then click Edit. In the
SSL Certificate list, select Test Local SSL Certificate. Click OK to
save the settings, and then click Close.
|
9. | Double-click SSL Settings in Features View. Enable the Require SSL option, and then click Apply.
|
10. | Click the Back button to return to Features View for Default Web Site. In the Actions pane, choose Browse *:80(http).
This will launch Internet Explorer and attempt to connect to the site,
using a non-SSL (HTTP) connection. Note that you receive an error
stating, “The page you are trying to access is secure with Secure
Sockets Layer (SSL).” Close Internet Explorer.
|
11. | In IIS Manager, click Browse *:443 (https) in the Actions pane.
Note that, this time, you receive a warning stating that there is a
problem with the Web site’s security certificate. This is because a
self-signed certificate was not issued by a trusted CA.
|
12. | To access the site anyway, click Continue To This Website.
Note that the address bar turns red, and a Certificate Error message appears. The site content is, however, accessible.
|
13. | When you are finished, close Internet Explorer.
|
14. | In
IIS Manager, double-click the SSL Settings feature for Default Web
Site, and disable the Require SSL option. Click Apply in the Actions
pane to save the setting.
|
15. | When you are finished, close IIS Manager. |
